Computing systems, e.g., servers, desktop computers, and mobile devices such as portable computers, mobile phones, personal digital assistants and the like conventionally include one or more processors, volatile and nonvolatile memory, controllers, and peripheral devices such as a keyboard, keypad, mouse, display, earpiece, etc. The various components of a computing system are interconnected via one or more system and/or peripheral buses over which data, address and/or control information is transferred between peripheral devices and processor(s) included in the system.
When a peripheral device requires servicing, the device may activate an interrupt signal. An interrupt causes the system processor to temporarily halt normal program flow in order to service the interrupt request. Commonly, an interrupt controller prioritizes and processes the various interrupt signals generated by peripheral devices. As such, the interrupt controller functions as an interface between peripheral devices and the system processor. Thus, the system processor is not burdened with low-level tasks associated with managing, prioritizing and scheduling interrupt requests generated by various peripheral devices. Because the system processor does not initially interface directly with peripheral devices when servicing interrupt requests, the processor must be provided an address or other information for identifying an Interrupt Service Routine (ISR) corresponding to a peripheral device requesting servicing. An ISR services interrupts generated by a particular peripheral device. Commonly, multiple ISRs are maintained in memory, each associated with a different peripheral device.
In one conventional approach, an address associated with an ISR is passed to a system processor via a system bus. Particularly, an interrupt controller issues an interrupt request to the system processor. At the appropriate time, the system processor acknowledges the request. Such initial interrupt request and acknowledgment signaling commonly occurs over signal lines running directly between the interrupt controller and the system processor. After acknowledging the interrupt request, the system processor executes a common interrupt handler routine, often referred to as First-Level Interrupt Handler (FLIH) routine, for handling tasks common to all interrupts. For example, FLIH routines may save the status of the interrupted instruction or routine, determine the action required to process a particular interrupt and schedule the execution of device-specific ISRs, commonly referred to as Second-Level Interrupt Handler (SLIH) routines. SLIH routines process interrupts associated with particular peripheral devices. The system processor initiates an SLIH routine by accessing a memory location associated with the address information received from an interrupt controller.
The interrupt controller provides ISR address information to the system processor via the system bus. Transferring ISR address information via the system bus delays the initiation of a particular SLIH routine by the system processor. Depending upon the particular activity occurring within a computing system, the delay associated with acquiring ISR address information via the system bus can be lengthy. For example, if the system processor is reading or writing large amounts of data from memory or is servicing other peripheral devices, access to the system bus for purposes of acquiring address information can be significantly delayed.
A second conventional approach eliminates the delay associated with transferring ISR address information to a system processor via a system bus. Particularly, address information is passed directly to a system processor from an interrupt controller via a dedicated bus. For example, ARM Holdings plc offers a Vectored Interrupt Controller (part number PL192, document reference # ARM DDI 0273A) having a dedicated bus for passing ISR address information from an interrupt controller directly to a system processor. As such, the system processor can initiate corresponding SLIH routines more rapidly.
However, system processors do not conventionally store the ISR address information locally within the processor for subsequent use. Instead, when a conventional processor receives ISR address information from an interrupt controller over a dedicated bus, it immediately initiates a corresponding SLIH routine without first executing a common FLIH routine. That is, the processor immediately jumps to a memory location associated with a particular SLIH routine without executing common FLIH code. Thus, each SLIH routine must contain common first-level interrupt handling code which is duplicative, inefficient, increases the likelihood of errors, and reduces code portability.